docs: add branch strategy section to contributing guidelines #2
Conversation
Release-As: patch
There was a problem hiding this comment.
Pull request overview
Adds explicit branching guidance to CONTRIBUTING.md to clarify how contributors should branch and where to open PRs, aligning contribution flow with the repo’s main/develop release setup.
Changes:
- Added a new “Branch Strategy” section describing
mainvsdevelop. - Added contributor instructions for branching from
developand targeting PRs todevelop.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| **For all contributors:** | ||
| - Create a new branch from `develop` | ||
| - Open pull requests against `develop` (not `main`) | ||
|
|
There was a problem hiding this comment.
The guidance to branch from develop / open PRs against develop is repeated later under "Code Contributions". Consider de-duplicating (e.g., reference this section from the later bullets) so future updates don’t drift out of sync.
| - **main**: Always reflects the latest stable and released code | ||
| - **develop**: Contains accepted changes that will be part of the next release | ||
|
|
||
| **For all contributors:** | ||
| - Create a new branch from `develop` |
There was a problem hiding this comment.
In "Branch purposes" the branch names are bolded, but immediately below they’re referenced as code (e.g., develop on line 42). Consider formatting the branch names in the purposes list as code (main, develop) as well for consistency.
| - Open pull requests against `develop` (not `main`) | ||
|
|
||
| **For regular contributors:** | ||
| If your work depends on unreleased features or changes, base your work directly on `develop`. Pull requests merged into `develop` are considered accepted for now, but remain under maintainer control. Our team decides which changes move from `develop` to `main` for release, and may revert or modify any merged code if needed. |
There was a problem hiding this comment.
The subheading "For regular contributors" doesn’t match the content of the paragraph (it describes maintainer/release-manager control over what moves from develop to main). Consider renaming this subheading (e.g., "For maintainers" / "Release process") or rewriting the paragraph so it actually contains guidance for regular contributors.
| If your work depends on unreleased features or changes, base your work directly on `develop`. Pull requests merged into `develop` are considered accepted for now, but remain under maintainer control. Our team decides which changes move from `develop` to `main` for release, and may revert or modify any merged code if needed. | |
| If your work depends on unreleased features or changes, base your work directly on `develop`. Keep in mind that `develop` is a staging branch: features there may change before they are released to `main`, so treat them as experimental and be prepared to update your work if behavior changes. |
| - **main**: Always reflects the latest stable and released code | ||
| - **develop**: Contains accepted changes that will be part of the next release | ||
|
|
||
| **For all contributors:** |
There was a problem hiding this comment.
This section says "For all contributors" PRs should target develop, but elsewhere the repo docs say only feature PRs must target develop (README "Contributing" section). Please clarify the intended rule here (all PRs vs only feature/code PRs) to avoid conflicting guidance.
| **For all contributors:** | |
| **For feature and code contributions:** |
|
🎉 This PR is included in version 1.3.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
1 participant
Release-As: patch
Description
Give a summary of the change that you have made
Fixes #[ISSUENO]
Dependencies
Mention any dependencies/packages used
Future Improvements
Mention any improvements to be done in future related to any file/feature
Mentions
Mention and tag the people
Screenshots of relevant screens
Add screenshots of relevant screens
Developer's checklist
If changes are made in the code: